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INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 2 


Status of this Memo 


This RFC suggests a method for personal computers and workstations to 
dynamically access mail from a mailbox server ("repository"). It 
obosoletes RFC 1064. This RFC specifies an Experimental Protocol for 
the Internet community. Discussion and suggestions for improvement 
are requested. Please refer to the current edition of the "IAB 
Official Protocol Standards" for the standardization state and status 
of this protocol. Distribution of this memo is unlimited. 


Introduction 


The intent of the Interactive Mail Access Protocol, Version 2 (IMAP2) 
is to allow a workstation, personal computer, or similar small 
machine to access electronic mail from a mailbox server. Since the 
distinction between personal computers and workstations is blurring 
over time, it is desirable to have a single solution that addresses 
the need in a general fashion. IMAP2 is the "glue" of a distributed 
electronic mail system consisting of a family of client and server 
implementations on a wide variety of platforms, from small single- 
tasking personal computing engines to complex multi-user timesharing 
systems. 


Although different in many ways from the Post Office Protocols (POP2 
and POP3, hereafter referred to collectively as "POP") described in 
RFC 937 and RFC 1081, IMAP2 may be thought of as a functional 
superset of these. RFC 937 was used as a model for this RFC. There 
was a cognizant reason for this; POP deals with a similar problem, 
albeit with a less comprehensive solution, and it was desirable to 
offer a basis for comparison. 


Like POP, IMAP2 specifies a means of accessing stored mail and not of 
posting mail; this function is handled by a mail transfer protocol 
such as SMTP (RFC 821). 


This protocol assumes a reliable data stream such as provided by TCP 


or any similar protocol. When TCP is used, the IMAP2 server listens 
on port 143. 
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System Model and Philosophy 


Electronic mail is a primary means of communication for the widely 
spread Internet community. The advent of distributed personal 
computers and workstations has forced a significant rethinking of the 
mechanisms employed to manage electronic mail. With mainframes, each 
user tends to receive and process mail at the computer he uses most 
of the time, his "primary host". The first inclination of many users 
when an independent workstation is placed in front of them is to 
begin receiving mail at the workstation, and many vendors have 
implemented facilities to do this. However, this approach has 
several disadvantages: 


(1) Personal computers and many workstations have a software 
design that gives full control of all aspects of the system to the 
user at the console. As a result, background tasks such as 
receiving mail may not run for long periods of time; either 
because the user is asking to use all the machine’s resources, or 
because the user has (perhaps accidentally) manipulated the 
environment in such a way that it prevents mail reception. In 
many personal computers, the operating system is single-tasking 
and this is the only mode of operation. Any of these conditions 
could lead to repeated failed delivery attempts by outside agents. 


(2) The hardware failure of a single machine can keep its user 
"off the air" for a considerable time, since repair of individual 
units may be delayed. Given the growing number of personal 
computers and workstations spread throughout office environments, 
quick repair of such systems is not assured. On the other hand, a 
central mainframe is generally repaired soon after failure. 


(3) Personal computers and workstations are often not backed up 
with as much diligence as a central mainframe, if at all. 


(4) It is more difficult to keep track of mailing addresses when 
each person is associated with a distinct machine. Consider the 
difficulty in keeping track of many postal addresses or phone 
numbers, particularly if there was no single address or phone 
number for an organization through which you could reach any 
person in that organization. Traditionally, electronic mail on 
the ARPANET involved remembering a name and one of several "hosts" 
(machines) whose name reflected the organization in which the 
individual worked. This was suitable at a time when most 
organizations had only one central host. It is less satisfactory 
today unless the concept of a host is changed to refer to an 
organizational entity and not a particular machine. 


(5) It is difficult to keep a multitude of heterogeneous machines 
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working properly with complex mailing protocols, making it 
difficult to move forward as progress is made in electronic 
communication and as new standards emerge. Each system has to 
worry about receiving incoming mail, routing and delivering 
outgoing mail, formatting, storing, and providing for the 
stability of mailboxes over a variety of possible filing and 
mailing protocols. 


Consequently, while a personal computer or workstation may be viewed 
as an Internet host in the sense that it implements TCP/IP, it should 
not be viewed as the entity that contains the user's mailbox. 


Instead, a mail server machine ("server", sometimes called a 
"repository") should hold the mailbox, and the personal computer or 
workstation (hereafter referred to as a "client") should access the 


mailbox via mail transactions. 


Because the mail server machine is isolated from direct user 
manipulation, it should achieve high software reliability easily, 
and, as a shared resource, it should also achieve high hardware 
reliability, perhaps through redundancy. The mail server may be 
accessed from arbitrary locations, allowing users to read mail across 
campus, town, or country using commonly available clients. 
Furthermore, the same user may access his mailbox from different 
clients at different times, and multiple users may access the same 
mailbox simultaneously. 


The mail server acts an an interface among users, data storage, and 
other mailers. A mail access protocol retrieves messages, accesss 
and changes properties of messages, and otherwise manages mailboxes. 
This differs from some approaches (e.g., Unix mail via NFS) in that 
the mail access protocol is used for all message manipulations, 
isolating the user and the client from all knowledge of how the data 
storage is used. This means that the mail server can use the data 
storage in whatever way is most efficient to organize the mail in 
that particular environment, without having to worry about storage 
representation compatibility across different machines. 


A mail access protocol further differs in that it transmits 
information only on demand. A well-designed mail access protocol 
requires considerably less network traffic than Unix mail via NFS, 
particularly when the mail file is large. The result is that a mail 
access protocol can scale well to situations of large mailboxes or 
networks with high latency or low speed. 


In defining a mail access protocol, it is important to keep in mind 
that the client and server form a macrosystem, in which it should be 
possible to exploit the strong points of both while compensating for 
each other’s weaknesses. Furthermore, it is desirable to allow for a 
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growth path beyond the hoary text-only RFC 822 protocol, specifically 
in the area of attachments and multi-media mail, to ease the eventual 
transition to ISO solutions. 


Unlike POP, IMAP2 has extensive features for remote searching and 
parsing of messages on the server. A free text search (optionally 
with other searching) can be made in the entire mailbox by the server 
and the results made available to the client without the client 
having to transfer the entire mailbox and searching itself. Since 
remote parsing of a message into a structured (and standard format) 
"envelope" is available, a client can display envelope information 
and implement commands such as REPLY without having any understanding 
of how to parse RFC 822, etc. headers. The effect of this is 
twofold: it further improves the ability to scale well in instances 
where network traffic must be reduced, and it reduces the complexity 
of the client program. 


Additionally, IMAP2 offers several facilities for managing individual 
message state and the mailbox as a whole beyond the simple "delete 
message" functionality of POP. Another benefit of IMAP2 is the use 
of tagged responses to reduce the possibility of synchronization 
errors and the concept of state on the client (a "local cache") that 
the server may update without explicit request by the client. These 
concepts and how they are used are explained under "Implementation 
Discussion" below. 


In spite of this functional richness, IMAP2 is a small protocol. 
Although servers should implement the full set of IMAP2 functions, a 
simple client can be written that uses IMAP2 in much the way as a POP 
client. 


A related protocol to POP and IMAP2 is the DMSP protocol of PCMAIL 
(RFC 1056). IMAP2 differs from DMSP more fundamentally, reflecting a 
differing architecture from PCMAIL. PCMAIL is either an online 
("interactive mode"), or offline ("batch mode") system with long-term 
shared state. Some POP based systems are also offline; in such 
systems, since there is no long-term shared state POP is little more 
than a download mechanism of the "mail file" to the client. IMAP2- 
based software is primarily an online system in which real-time and 
simultaneous mail access were considered important. 


In PCMAIL, there is a long-term client/server relationship in which 
some mailbox state is preserved on the client. There is a 
registration of clients used by a particular user, and the client 
keeps a set of "descriptors" for each message that summarize the 
message. The server and client synchronize their states when the 
DMSP connection starts up, and, if a client has not accessed the 
server for a while, the client does a complete reset (reload) of its 
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state from the server. 


In IMAP2-based software, the client/server relationship lasts only 
for the duration of the TCP connection. All mailbox state is 
maintained on the server. There is no registration of clients. The 
function of a descriptor is handled by a structured representation of 
the message "envelope" as noted above. There is no client/server 
synchronization since the client does not remember state between 
IMAP2 connections. This is not a problem since in general the client 
never needs the entire state of the mailbox in a single session, 
therefore there isn't much overhead in fetching the state information 
that is needed as it is needed. 


There are also some functional differences between IMAP2 and DMSP. 
DMSP has functions for sending messages, printing messages, listing 
mailboxes, and changing passwords, these are done outside IMAP2. 

DMSP has 16 binary flags of which 8 are defined by the system. IMAP2 
has flag names, there are currently 5 defined system flag names and a 
facility for some number (30 in the current implementations) of user 
flag names. IMAP2 has a sophisticated message search facility in the 
server to identify interesting messages based on dates, addresses, 
flag status, or textual contents without compelling the client to 
fetch this data for every message. 


It was felt that maintaining state on the client is advantageous only 
in those cases where the client is only used by a single user, or if 
there is some means on the client to restrict access to another 
user's data. It can be a serious disadvantage in an environment in 
which multiple users routinely use the same client, the same user 
routinely uses different clients, and where there are no access 
restrictions on the client. It was also observed that most user mail 
access is to a small set of "interesting" messages, which were either 
new mail or mail based on some user-selected criteria. Consequently, 
IMAP2 was designed to easily identify those "interesting" messages so 
that the client could fetch the state of those messages and not those 
that were not "interesting". 


The Protocol 


The IMAP2 protocol consists of a sequence of client commands and 
server responses, with server data interspersed between the 
responses. Unlike most Internet protocols, commands and responses 
are tagged. That is, a command begins with a unique identifier 
(typically a short alphanumeric sequence such as a Lisp "gensym" 
function would generate e.g., A0001, A0002, etc.), called a tag. The 
response to this command is given the same tag from the server. 
Additionally, the server may send an arbitrary amount of "unsolicited 
data", which is identified by the special reserved tag of "4". There 
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is another special reserved tag, "+", discussed below. 


The server must be listening for a connection. When a connection is 
opened the server sends an unsolicited OK response as a greeting 
message and then waits for commands. 


The client opens a Connection and waits for the greeting. The client 
must not send any commands until it has received the greeting from 
the server. 


Once the greeting has been received, the client may begin sending 
commands and is not under any obligation to wait for a server 
response to this command before sending another command, within the 
constraints of TCP flow control. When commands are received the 
server acts on them and responds with command responses, often 
interspersed with data. The effect of a command can not be 
considered complete until a command response with a tag matching the 
command is received from the server. 


Although all known IMAP2 servers at the time of this writing process 
commands to completion before processing the next command, it is not 
required that a server do so. However, many commands can affect the 
results of other commands, creating processing-order dependencies 
(or, for SEARCH and FIND, ambiguities about which data is associated 
with which command). All implementations that operate in a non- 
lockstep fashion must recognize such dependencies and defer or 
synchronize execution as necessary. In general, such multi- 
processing is limited to consecutive FETCH commands. 


Generally, the first command from the client is a LOGIN command with 
user name and password arguments to establish identity and access 
authorization, unless this has already been accomplished through 


other means, e.g. Kerberos. Until identity and access authorization 
have been established, no operations other than LOGIN or LOGOUT are 
permitted. 


Once identity and authorization have been established, the client 
must send a SELECT command to access the desired mailbox, no mailbox 
is selected by default. SELECT's argument is implementation- 
dependent, however the word "INBOX" must be implemented to mean the 
primary or default mailbox for this user, independent of any other 
server semantics. On a successful SELECT, the server will send a 
list of valid flags, number of messages, and number of messages 
arrived since last access for this mailbox as unsolicited data, 
followed by an OK response. The client may terminate access to this 
mailbox and access a different one with another SELECT command. 


The client reads mailbox information with FETCH commands. The actual 
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data is transmitted via the unsolicited data mechanism (that is, 
FETCH should be viewed as instructing the server to include the 
desired data along with any other data it wishes to transmit to the 
client). There are three major categories of data that may be 
fetched. 


The first category is data that is associated with a message as an 
entity in the mailbox. There are now three such items of data: the 
"internal date", the "RFC 822 size", and the "flags". The internal 
date is the date and time that the message was placed in the mailbox. 
The RFC 822 size is subject to deletion in the future; it is the size 
in bytes of the message, expressed as an RFC 822 text string. 


Current clients only use it as part of a status display line. The 
flags are a list of status flags associated with the message (see 
below). All the first category data can be fetched by using the 


macro-fetch word "FAST", that is, "FAST" expands to "(FLAGS 
INTERNALDATE RFC822.SIZE)". 


The second category is that data that describes the composition and 
delivery information of a message, that is, information such as the 
message sender, recipient lists, message-ID, subject, etc. This is 
the information that is stored in the message header in RFC 822 
format message and is traditionally called the "envelope". [Note: 
this should not be confused with the SMTP (RFC 821) envelope, which 
is strictly limited to delivery information.] IMAP2 defines a 
structured and unambiguous representation for the envelope that is 
particularly suited for Lisp-based parsers. A client can use the 
envelope for operations such as replying and not worry about RFC 822 
at all. Envelopes are discussed in more detail below. The first two 
categories of data can be fetched together by using the macro-fetch 
word "ALL"; that is, "ALL" expands to "(FLAGS INTERNALDATE 
RFC822.SIZE ENVELOPE)". 


The third category is that data that is intended for direct human 
viewing. The present RFC 822 based IMAP2 defines three such items: 
RFC822.HEADER, RFC822.TEXT, and RFC822 (the latter being the two 
former appended together in a single text string). RFC822.HEADER is 
the "raw", unprocessed RFC 822 format header of the message. 
Fetching "RFC822" is equivalent to fetching the RFC 822 
representation of the message as stored on the mailbox without any 
filtering or processing. 


An intelligent client will "FETCH ALL" for some (or all) of the 
messages in the mailbox for use as a presentation menu, and when the 
user wishes to read a particular message will "FETCH RFC822.TEXT" to 
get the message body. A more primitive client could, of course, 
simply "FETCH RFC822" a‘la POP-type functionality. 
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The client can alter certain data (currently only the flags) by a 
STORE command. As an example, a message is deleted from a mailbox by 
a STORE command that includes the \DELETED flag as a flag being set. 


Other client operations include copying a message to another mailbox 
(COPY command), permanently removing deleted messages (EXPUNGE 
command), checking for new messages (CHECK command), and searching 
for messages that match certain criteria (SEARCH command). 


The client terminates the session with the LOGOUT command. The 
server returns a "BYE" followed by an "OK". 


A Typical Scenario 


Client Server 
(Wait for Connection) 
(Open Connection] --5 
<--— * OK IMAP2 Server Ready 
{Wait for command} 
A001 LOGIN Fred Secret --> 
<-- A001 OK User Fred logged in 
{Wait for command} 
A002 SELECT INBOX --> 
<-- * FLAGS (Meeting Notice \Answered 
\Flagged \Deleted \Seen) 
<-- * 19 EXISTS 
<-- * 2 RECENT 
<-- A0002 OK Select complete 
{Wait for command} 


A003 FETCH 1:19 ALL --> 


<-- * 18 Feteh (ne ) 
get 19 Ee EE ae x ) 
<-- A003 OK Fetch complete 
{Wait for command} 
A004 FETCH 8 RFC822.TEXT --> 
<-- + 8 Fetch (RFC822.TEXT {893} 
...893 characters of text... 
SS A 
<-- A004 OK Fetch complete 
{Wait for command} 
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A005 STORE 8 +Flags \Deleted --> 
<-- * 8 Store (Flags (\Deleted 
\Seen) ) 
<-- A005 OK Store complete 
{Wait for command} 
A006 EXPUNGE --> 
<-- * 19 EXISTS 
<-- * 8 EXPUNGE 
<-- * 18 EXISTS 
<-- A006 Expunge complete 
{Wait for command} 
A007 LOGOUT --> 
<-- * BYE IMAP2 server quitting 
<-- A007 OK Logout complete 
{Close Connection} --58-- {Close connection} 


{Go back to start} 
Conventions 


The following terms are used in a meta-sense in the syntax 
specification below: 


An ASCII-STRING is a sequence of arbitrary ASCII characters. 
An ATOM is a sequence of ASCII characters delimited by SP or CRLF. 


A CHARACTER is any ASCII character except """", "{", CR, LF, "%" 
or TAM 


LA 


A CRLF is an ASCII carriage-return character followed immediately 
by an ASCII linefeed character. 


A NUMBER is a sequence of the ASCII characters that represent 
decimal numerals ("0" through "9"), delimited by SP, CRLF, ",", or 


LA LA 
"en 


A SP is the ASCII space character. 


A TEXT_LINE is a human-readable sequence of ASCII characters up to 
but not including a terminating CRLF. 


A common field in the IMAP2 protocol is a STRING, which may be an 
ATOM, QUOTED-STRING (a sequence of CHARACTERs inside double-quotes), 


or a LITERAL. A literal consists of an open brace ("{"), a number, a 
close brace ("}"), a CRLF, and then an ASCII-STRING of n characters, 
where n is the value of the number inside the brace. In general, a 


string should be represented as an ATOM or QUOTED-STRING if at all 
possible. The semantics for QUOTED-STRING or LITERAL are checked 
before those for ATOM; therefore an ATOM used in a STRING may only 


Crispin [Page 9] 


RFC 1176 IMAP2 August 1990 


contain CHARACTERs. Literals are most often sent from the server to 
the client, in the rare case of a client to server literal there is a 
special consideration (see the "+ text" response below). 


Another important field is the SEQUENCE, which identifies a set of 
messages by consecutive numbers from 1 to n where n is the number of 
messages in the mailbox. A sequence may consist of a single number, 
a pair of numbers delimited by colon (equivalent to all numbers 
between those two numbers), or a list of single numbers or number 
pairs. For example, the sequence 2,4:7,9,12:15 is equivalent to 
2,4,5,6,7,9,12,13,14,15 and identifies all those messages. 


Definitions of Commands and Responses 


Summary of Commands and Responses 


Commands Responses 

tag NOOP tag OK text 
tag LOGIN user password tag NO text 
tag LOGOUT tag BAD text 


tag SELECT mailbox 

tag BBOARD bulletin_board 
tag FIND MAILBOXES pattern 
tag FIND BBOARDS pattern 
tag CHECK 


* number message_data 
* FLAGS flag_list 
SEARCH sequence 
BBOARD string 
MATLBOX string 


+ + + * + + + + 


tag EXPUNGE BYE text 
tag COPY sequence mailbox OK text 
tag FETCH sequence data NO text 
tag STORE sequence data value BAD text 
tag SEARCH search_program text 


Commands 
tag NOOP 


The NOOP command returns an OK to the client. By itself, it does 
nothing, but certain things may happen as side effects. For 
example, server implementations that implicitly check the mailbox 
for new mail may do so as a result of this command. The primary 
use of this command is to for the client to see if the server is 
still alive (and notify the server that the client is still alive, 
for those servers that have inactivity autologout timers). 


tag LOGIN user password 


The LOGIN command identifies the user to the server and carries 
the password authenticating this user. This information is used 
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by the server to control access to the mailboxes. 


EXAMPLE: A001 LOGIN SMITH SESAME 
logs in as user SMITH with password SESAME. 


tag LOGOUT 


The LOGOUT command informs the server that the client is done with 
the session. The server should send an unsolicited BYE response 
before the (tagged) OK response, and then close the network 
connection. 


tag SELECT mailbox 


The SELECT command selects a particular mailbox. The server must 
check that the user is permitted read access to this mailbox. 
Before returning an OK to the client, the server must send the 
following unsolicited data to the client: 

FLAGS mailbox’s defined flags 

<n> EXISTS the number of messages in the mailbox 

<n> RECENT the number of new messages in the mailbox 
in order to define the initial state of the mailbox at the client. 


Multiple SELECT commands are permitted in a session, in which case 
the previous mailbox is automatically deselected when a new SELECT 
is made. 


The default mailbox for the SELECT command is INBOX, which is a 
special name reserved to mean "the primary mailbox for this user 
on this server". The format of other mailbox names is operating 
system dependent (as of this writing, it reflects the filename 
path of the mailbox file on the current servers). 


It is customary, although not required, for the text of an OK 
response to the SELECT command to begin with either "[READ-ONLY]" 
or “[READ-WRITE]" to show the mailbox’s access status. 


EXAMPLE: A002 SELECT INBOX 
selects the default mailbox. 


tag BBOARD bulletin_board 


The BBOARD command is equivalent to SELECT, and returns the same 
output. However, it differs from SELECT in that its argument is a 
shared mailbox (bulletin board) name instead of an ordinary 
mailbox. The format of a bulletin name is implementation 
specific, although it is strongly encouraged to use something that 
resembles a name in a generic sense and not a file or mailbox name 
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on the particular system. There is no requirement that a bulletin 
board name be a mailbox name or a file name (in particular, Unix 
netnews has a completely different namespace from mailbox or file 
names). 


Support for BBOARD is optional. 


tag FIND MAILBOXES pattern 


The FIND MAILBOXES command accepts as an argument a pattern 
(including wildcards) that specifies some set of mailbox names 
that are usable by the SELECT command. The format of mailboxes is 
implementation dependent. The special mailbox name INBOX is not 
included in the output. 


Two wildcard characters are defined, "*" specifies any number 
(including zero) characters may match at this position and "%" 
specifies a single character may match at this position. For 
example, FOO*BAR will match FOOBAR, FOOD.ON.THE.BAR and FOO.BAR, 
whereas FOOSBAR will match only FOO.BAR. "*" will match all 
mailboxes. 


The FIND MAILBOXES command will return some set of unsolicited 
MAILBOX replies that have as their value a single mailbox name. 


EXAMPLE: A002 FIND MAILBOXES * 
* MAILBOX FOOBAR 
* MAILBOX GENERAL 
A002 FIND completed 


Although the use of explicit file or path names for mailboxes is 
discouraged by this standard, it may be unavoidable. It is 
important that the value returned in the MAILBOX unsolicited reply 
be usable in the SELECT command without remembering any path 
specification that may have been used in the FIND MAILBOXES 
pattern. 


Support for FIND MAILBOXES is optional. If a client’s attempt 
returns BAD as a response then the client can make no assumptions 
about what mailboxes exist on the server other than INBOX. 


tag FIND BBOARDS pattern 
The FIND BBOARDS command accepts as an argument a pattern that 
specifies some set of bulletin board names that are usable by the 


BBOARD command. Wildcards are permitted as in FIND MAILBOXES. 


The FIND BBOARDS command will return some set of unsolicited 
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BBOARD replies that have as their value a single bulletin board 
name. 


EXAMPLE: A002 FIND BBOARDS * 
x BBOARD FOOBAR 
* BBOARD GENERAL 
A002 FIND completed 


Support for FIND BBOARDS is optional. If a client’s attempt 
returns BAD as a response then the client can make no assumptions 
about what bulletin boards exist on the server, or that they exist 
at all. 


tag CHECK 


The CHECK command forces a check for new messages and a rescan of 
the mailbox for internal change for those implementations that 
allow multiple simultaneous read/write access to the same mailbox. 
It is recommend that periodic implicit checks for new mail be done 
by servers as well. The server should send unsolicited EXISTS and 
RECENT responses with the current status before returning an OK to 
the client. 


tag EXPUNGE 


The EXPUNGE command permanently removes all messages with the 
\DELETED flag set in its flags from the mailbox. Before returning 
an OK to the client, for each message that is removed, an 
unsolicited EXPUNGE response is sent. The message number for each 
successive message in the mailbox is immediately decremented by 1; 
this means that if the last 5 messages in a 9-message mail file 
are expunged you will receive 5 unsolicited EXPUNGE responses for 
message 5. To ensure mailbox integrity and server/client 
synchronization, it is recommended that the server do an implicit 
check before commencing the expunge and again when the expunge is 
completed. Furthermore, if the server allows multiple 
simultaneous access to the same mail file the server must lock the 
mail file for exclusive access while an expunge is taking place. 


EXPUNGE is not allowed if the user does not have write access to 
this mailbox. 


tag COPY sequence mailbox 
The COPY command copies the specified message(s) to the specified 
destination mailbox. If the destination mailbox does not exist, 


the server should create it. Before returning an OK to the 
client, the server should return an unsolicited <n> COPY response 
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for each message copied. A copy should set the \SEEN flag for all 
messages that were successfully copied (provided, of course, that 
the user has write access to this mailbox). 


EXAMPLE: A003 COPY 2:4 MEETING 
copies messages 2, 3, and 4 to mailbox "MEETING". 


COPY is not allowed if the user does not have write access to the 
destination mailbox. 


tag FETCH sequence data 


The FETCH command retrieves data associated with a message in the 
mailbox. The data items to be fetched may be either a single atom 
or an S-expression list. The currently defined data items that 
can be fetched are: 


ALL Macro equivalent to: 
(FLAGS INTERNALDATE RFC822.SIZE ENVELOPE) 


ENVELOPE The envelope of the message. The envelope is 
computed by the server by parsing the RFC 822 
header into the component parts, defaulting 
various fields as necessary. 


FAST Macro equivalent to: 
(FLAGS INTERNALDATE RFC822.SIZE) 


FLAGS The flags that are set for this message. 
This may include the following system flags: 


NRECENT Message arrived since the 
previous time this mailbox 
was read 

\SEEN Message has been read 


\ANSWERED Message has been answered 
\ FLAGGED Message is "flagged" for 
urgent/special attention 
\DELETED Message is "deleted" for 
removal by later EXPUNGE 


INTERNALDATE The date and time the message was written to 
the mailbox. 
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RFC822 The message in RFC 822 format. The \SEEN 
flag is implicitly set; if this causes the 
flags to change they should be included as 
part of the fetch results. This is the 
concatenation of RFC822.HEADER and RFC822.TEXT. 


RFC822.HEADER The "raw" RFC 822 format header of the message 
as stored on the server. 


RFC822.SIZE The number of characters in the message as 
expressed in RFC 822 format. 


RFC822.TEXT The text body of the message, omitting the 
RFC 822 header. The \SEEN flag is implicitly 
set as with RFC822 above. 
EXAMPLES: 
A003 FETCH 2:4 ALL 
fetches the flags, internal date, RFC 822 size, and envelope 


for messages 2, 3, and 4. 


A004 FETCH 3 RFC822 
fetches the RFC 822 representation for message 3. 


A005 FETCH 4 (FLAGS RFC822.HEADER) 
fetches the flags and RFC 822 format header for message 4. 


Note: An attempt to FETCH already-transmitted data may have no 
result. See the Implementation Discussion below. 


tag STORE sequence data value 


The STORE command alters data associated with a message in the 
mailbox. The currently defined data items that can be stored are: 


FLAGS Replace the flags for the message with the 
argument (in flag list format). 


+F LAGS Add the flags in the argument to the 
message’s flag list. 


-FLAGS Remove the flags in the argument from the 
message’s flag list. 


STORE is not allowed if the user does not have write access to 
this mailbox. 
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EXAMPLE: A003 STORE 2:4 +FLAGS (NDELETED) 
marks messages 2, 3, and 4 for deletion. 


T 


tag SEARCH search_criteria 


The SEARCH command searches the mailbox for messages that match 
the given set of criteria. The unsolicited SEARCH <1#number> 
response from the server is a list of messages that express the 
intersection (AND function) of all the messages which match that 
criteria. For example, 

A003 SEARCH DELETED FROM "SMITH" SINCE 1-OCT-87 
returns the message numbers for all deleted messages from Smith 
that were placed in the mail file since October 1, 1987. 


In all search criteria which use strings, a message matches the 
criteria if the string is a case-independent substring of that 
field. The currently defined criteria are: 


ALL All messages in the mailbox; the default 
initial criterion for ANDing. 


ANSWERED Messages with the \ANSWERED flag set. 


BCC string Messages which contain the specified string 
in the envelope’s BCC field. 


BEFORE date Messages whose internal date is earlier than 
the specified date. 


BODY string Messages which contain the specified string 
in the body of the message. 


CC string Messages which contain the specified string 
in the envelope’s CC field. 


DELETED Messages with the \DELETED flag set. 
FLAGGED Messages with the \FLAGGED flag set. 
FROM string Messages which contain the specified string 


in the envelope’s FROM field. 


KEYWORD flag Messages with the specified flag set. 


NEW Messages which have the \RECENT flag set but 
not the \SEEN flag. This is functionally 
equivalent to "RECENT UNSEEN". 
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OLD 


ON date 


RECENT 
SEEN 


SINCE date 


SUBJECT string 


TEXT string 


TO string 


UNANSWERED 


UNDELETED 


UNF LAGGED 


UNKEYWORD flag 


UNSEEN 
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Messages which do not have the \RECENT flag 
set. 


Messages whose internal date is the same as 
the specified date. 


Messages which have the \RECENT flag set. 
Messages which have the \SEEN flag set. 


Messages whose internal date is later than 
the specified date. 


Messages which contain the specified string 
in the envelope’s SUBJECT field. 


Messages which contain the specified string. 


Messages which contain the 


specified string in 


the envelope’s TO field. 

Messages which do not have the \ANSWERED flag 
set. 

Messages which do not have the \DELETED flag 
set. 

Messages which do not have the \FLAGGED flag 
set. 

Messages which do not have the specified flag 
set. 

Messages which do not have the \SEEN flag set. 


1990 
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Responses 

tag OK text 
This response identifies successful completion of the command with 
that tag. The text is a line of human-readable text that may be 
useful in a protocol telemetry log for debugging purposes. 

tag NO text 
This response identifies unsuccessful completion of the command 
with that tag. The text is a line of human-readable text that 
probably should be displayed to the user in an error report by the 
client. 

tag BAD text 
This response identifies faulty protocol received from the client, 
The text is a line of human-readable text that should be recorded 
in any telemetry as part of a bug report to the maintainer of the 
client. 


x number message data 


This response occurs as a result of several different commands. 
The message data is one of the following: 


EXISTS The specified number of messages exists in the mailbox. 


RECENT The specified number of messages have arrived since the 
previous time this mailbox was read. 


EXPUNGE The specified message number has been permanently 
removed from the mailbox, and the next message in the 
mailbox (if any) becomes that message number. 


STORE data 
Obsolete and functionally equivalent to FETCH. 


FETCH data 
This is the principle means by which data about a 
message is returned to the client. The data is ina 


Lisp-like S-expression property list form. The current 
properties are: 


ENVELOPE An S-expression format list that describes the 


envelope of a message. The envelope is computed 
by the server by parsing the RFC 822 header into 
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INTERNALDATE 


RFC822 


RFC822.HEADER 
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the component parts, defaulting various fields 
as necessary. 


The fields of the envelope are in the following 
order: date, subject, from, sender, reply-to, to, 
cc, bec, in-reply-to, and message-id. The date, 
subject, in-reply-to, and message-id fields are 
strings. The from, sender, reply-to, to, cc, 

and bcc fields are lists of addresses. 


An address is an S-expression format list that 
describes an electronic mail address. The fields 
of an address are in the following order: 
personal name, source-route (a.k.a. the 
at-domain-list in SMTP), mailbox name, and 

host name. 


Any field of an envelope or address that is 

not applicable is presented as the atom NIL. 

Note that the server must default the reply-to 

and sender fields from the from field, a client is 
not expected to know to do this. 


An S-expression format list of flags that are set 
for this message. This may include the following 
system flags: 


NRECENT Message arrived since the 
previous time this mailbox 
was read 

\ SEEN Message has been read 

\ANSWERED Message has been answered 

\ FLAGGED Message is "flagged" for 
urgent/special attention 

\DELETED Message is "deleted" for 


removal by later EXPUNGE 


A string containing the date and time the 
message was written to the mailbox. 


A string expressing the message in RFC 822 
format. 


A string expressing the RFC 822 format 
header of the message 


A number indicating the number of 
characters in the message as expressed 
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in RFC 822 format. 


RFC822. TEXT A string expressing the text body of the 
message, omitting the RFC 822 header. 


x PLAGS flag list 


This response occurs as a result of a SELECT command. The flag 
list are the list of flags (at a minimum, the system-defined 
flags) that are applicable for this mailbox. Flags other than the 
system flags are a function of the server implementation. 


* SEARCH number(s) 


This response occurs as a result of a SEARCH command. The 
number(s) refer to those messages that match the search criteria. 
Each number is delimited by a space, e.g., "SEARCH 2 3 6". 


* BBOARD string 


This response occurs as a result of a FIND BBOARDS command. The 
string is a bulletin board name that matches the pattern in the 
command. 


* MAILBOX string 


This response occurs as a result of a FIND MAILBOXES command. The 
string is a mailbox name that matches the pattern in the command. 


* BYE text 


This response identifies that the server is about to close the 
connection. The text is a line of human-readable text that should 
be displayed to the user in a status report by the client. This 
may be sent as part of a normal logout sequence, or as a panic 
shutdown announcement by the server. It is also used by some 
servers as an announcement of an inactivity autologout. 


* OK text 


This response identifies normal operation on the server. No 
special action by the client is called for, however, the text 
should be displayed to the user in some fashion. This is 
currently only used by servers at startup as a greeting message to 
show they are ready to accept the first command. 
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x NO text 


This response identifies a warning from the server that does not 
affect the overall results of any particular request. The text is 
a line of human-readable text that should be presented to the user 
as a warning of improper operation. 


x BAD text 


This response identifies a serious error at the server, it may 
also indicate faulty protocol from the client in which a tag could 
not be parsed. The text is a line of human-readable text that 
should be presented to the user as a serious or possibly fatal 
error. It should also be recorded in any telemetry as part of a 
bug report to the maintainer of the client and server. 


+ text 


This response identifies that the server is ready to accept the 
text of a literal from the client. Normally, a command from the 
client is a single text line. If the server detects an error in 
the command, it can simply discard the remainder of the line. It 
cannot do this for commands that contain literals, since a literal 
can be an arbitrarily long amount of text, and the server may not 
even be expecting a literal. This mechanism is provided so the 
client knows not to send a literal until the server expects it, 
preserving client/server synchronization. 


In practice, this condition is rarely encountered. In the current 
protocol, the only client command likely to contain a literal is 
the LOGIN command. Consider a server that validates the user 
before checking the password. If the password contains "funny" 
characters and hence is sent as a literal, then if the user is 
invalid an error would occur before the password is parsed. 


No such synchronization protection is provided for literals sent 
from the server to the client, for performance reasons. Any 
synchronization problems in this direction would be caused by a 
bug in the client or server. 
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Sample IMAP2 session 


The following is a transcript of an IMAP2 session. Server output is 
identified by "S:" and client output by "U:". In cases where lines 

are too long to fit within the boundaries of this document, the line 
is continued on the next line. 


S: x OK SUMEX-AIM.Stanford.EDU Interim Mail Access Protocol II Service 
6.1(349) at Thu, 9 Jun 88 14:58:30 PDT 

U a001 login crispin secret 

SE a002 OK User CRISPIN logged in at Thu, 9 Jun 88 14:58:42 PDT, job 76 

U: a002 select inbox 

S: x FLAGS (Bugs SF Party Skating Meeting Flames Request AI Question 
Note \XXXX \ YYYY \Answered \Flagged \Deleted \Seen) 


S * 16 EXISTS 

S: * 0 RECENT 

S: a002 OK Select complete 

U: a003 fetch 16 all 

S * 16 Fetch (Flags (\Seen) InternalDate " 9-Jun-88 12:55:44 PDT" 


RFC822.Size 637 Envelope ("Sat, 4 Jun 88 13:27:11 PDT" 
"INFO-MAC Mail Message" (("Larry Fagan" NIL "FAGAN" 
"SUMEX-AIM.Stanford.EDU" (("Larry Fagan" NIL "FAGAN" 
"SUMEX-AIM.Stanford.EDU" (("Larry Fagan" NIL "FAGAN" 
"SUMEX-AIM.Stanford.EDU" ( (NIL NIL "rindflEISCH" 
"SUMEX-AIM.Stanford.EDU" NIL NIL NIL 
"<12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU>") ) 

a003 OK Fetch completed 

a004 fetch 16 rfc822 

* 16 Fetch (RFC822 {637} 

Mail-From: RINDFLEISCH created at 9-Jun-88 12:55:43 

Mail-From: FAGAN created at 4-Jun-88 13:27:12 

Date: Sat, 4 Jun 88 13:27:11 PDT 

From: Larry Fagan <FAGAN@SUMEX-AIM.Stanford.EDU> 

To: rindflEISCH@SUMEX-AIM.Stanford.EDU 

Subject: INFO-MAC Mail Message 

Message-ID: <12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU> 

ReSent-Date: Thu, 9 Jun 88 12:55:43 PDT 

ReSent-From: TC Rindfleisch <Rindfleisch@SUMEX-AIM.Stanford.EDU> 

ReSent-To: Yeager@SUMEX-AIM.Stanford.EDU, 

Crispin@SUMEX-AIM. Stanford. EDU 

ReSent-Message-ID: 
<12405133897.80.RINDFLEISCH@SUMEX-AIM. Stanford. EDU 


~ e e wa 


) 
) 
) 
) 


NANNNNNNNNNNAN 


n 


The file is <info-mac>usenetv4—-55.arc 
Larry 


NNnNNNNN 


a004 OK Fetch completed 
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U: a005 logout 
Si * BYE DEC-20 IMAP II server terminating connection 
S: a005 OK SUMEX-AIM.Stanford.EDU Interim Mail Access Protocol 


Service logout 
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Implementation Discussion 


There are several advantages to the scheme of tags and unsolicited 
responses. First, the infamous synchronization problems of SMTP and 
similar protocols do not happen with tagged commands; a command is 
not considered satisfied until a response with the same tag is seen. 
Tagging allows an arbitrary amount of other responses ("unsolicited" 
data) to be sent by the server with no possibility of the client 
losing synchronization. Compare this with the problems that FTP or 
SMTP clients have with continuation, partial completion, and 
commentary reply codes. 


Another advantage is that a non-lockstep client implementation is 
possible. The client could send a command, and entrust the handling 
of the server responses to a different process that would signal the 
client when the tagged response comes in. Under certain 
circumstances, the client may have more than one command outstanding. 


It was observed that synchronization problems can occur with literals 
if the literal is not recognized as such. Fortunately, the cases in 
which this can happen are rare; a mechanism (the special "+" tag 
response) was introduced to handle those few cases. The proper way 
to address this problem is probably to move towards a record-oriented 
architecture instead of the text stream model provided by TCP. 


An IMAP2 client must maintain a local cache of data from the mailbox. 
This cache is an incomplete model of the mailbox, and at startup is 
empty. A listener processes all unsolicited data, and updates the 
cache based on this data. If a tagged response arrives, the listener 
unblocks the process that sent the tagged request. 


Unsolicited data needs some discussion. Unlike most protocols, in 
which the server merely does the client’s bidding, an IMAP2 server 
has a semi-autonomous role. By sending "unsolicited data", the 
server is in effect sending a command to the client -- to update or 
extend the client’s cache with new information from the server. In 
other words, a "fetch" command is merely a request to the server to 
ensure that the client’s cache has the most up-to-date version of the 
requested information. A server acknowledgement to the "fetch" is a 
statement that all the requested data has been sent. 


Although no current server does this, a server is not obliged by the 
protocol to send data that it has already sent and is unchanged. An 
exception to this is the actual message text fetching operations 
(RFC822, RFC822.HEADER, and RFC822.TEXT), owing to the possibly 
excessive resource consumption of maintaining this data in a cache. 
It can not be assumed that a FETCH will transmit any data; only that 
an OK to the FETCH means that the client’s cache has the most up-to- 
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date information. 


When a mailbox is selected, the initial unsolicited data from the 
server arrives. The first piece of data is the number of messages. 
By sending a new EXISTS unsolicited data message the server causes 
the client to resize its cache (this is how newly arrived mail is 


handled). If the client attempts to access information from the 
cache, it will encounter empty spots that will trigger "fetch" 
requests. The request would be sent, some unsolicited data including 


the answer to the fetch will flow back, and then the "fetch" response 
will unblock the client. 


People familiar with demand-paged virtual memory operating system 


design will recognize this model as being similar to page-fault 
handling on a demand-paged system. 
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The following syntax specification uses the augmented Backus-Naur 
Form (BNF) notation as specified in RFC 822 with one exception; the 


delimiter used with the "#" construct is a single space 


a comma. 


address 


addr adl 
addr host 
addr mailbox 
addr name 
bboard 

check 


copy 


data 


date 


envelope 


env_bcc 

env_cc 

env_date 
env_from 

env in-reply-to 
env message-id 


env reply-to 


Crispin 


(SP) and not 


"(" addr name SP addr adl SP addr mailbox SP 


addr host ")" 
nil / string 
nil / string 
nil / string 
nil / string 
"BBOARD" SP string 


"CHECK" 


"COPY" SP sequence SP mailbox 


("FLAGS" SP flag_list / "SEARCH" SP l#number / 


"BYE" SP text_line / 
"NO" SP text_line / 


" OK " 
" BAD " 


SP text line / 
SP text line) 


string in form "dd-mmm-yy hh:mm:ss-zzz" 


"(" env date SP env subject SP env from SP 
env sender SP env reply-to SP env to SP 
env cc SP env bcc SP env in-reply-to SP 


env message-id ")" 


nil / "(" 1*address 
nil / "(" 1*address 
string 

nil / "(" 1*address 


nil / string 
nil / string 


nil / "(" 1*address 


WW " 


") " 


"y " 


WW " 
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env sender ::= nil / "(" 1*address "in 

env subject ::= nil / string 

env to ::5 nil / "(" 1l*address "in 

expunge ::= "EXPUNGE" 

fetch ::= "FETCH" SP sequence SP ("ALL" / "FAST" / 
fetch att / "(" l#fetch_att ")") 

fetch att ::= "ENVELOPE" / "FLAGS" / “INTERNALDATE" / 


"RFC822" / "RFC822.HEADER" / "RFC822.SIZE" / 
"RFC822.TEXT" 


find ::= "FIND" SP find option SP string 

find option ::= "MAILBOXES" / "BBOARDS" 

flag list ::= ATOM / "(" 1#ATOM ")" 

literal ::= "{" NUMBER "}" CRLF ASCII-STRING 

login ::= "LOGIN" SP userid SP password 

logout ::= "LOGOUT" 

mailbox ::5 "INBOX" / string 

msg_copy ::5 "COPY" 

msg_data ::= (msg exists / msg recent / msg_expunge / 


msg fetch / msg copy) 


msg exists ::= "EXISTS" 

msg_expunge ::= "EXPUNGE" 

msg_fetch ::= ("FETCH" / "STORE") SP "(" 1#("ENVELOPE" SP 
envelope / "FLAGS" SP "(" 1#(recent_flag 
flag list) ")" / "INTERNALDATE" SP date / 


"RFC822" SP string / "RFC822.HEADER" SP string / 
"RFC822.SIZE" SP NUMBER / "RFC822.TEXT" SP 


string) ")" 
msg_recent ::= "RECENT" 
msg_num ::= NUMBER 
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nil ::= "NIL" 

noop ::= "NOOP" 

password ::= string 

recent_flag ::= "\RECENT" 

ready ::= "+" SP text line 

request ::= tag SP (noop / login / logout / select / check / 


expunge / copy / fetch / store / search / find / 
bboard) CRLF 


response ::5 tag SP ("OK" / "NO" / "BAD") SP text line CRLF 


search ::= "SEARCH" SP 1#("ALL" / "ANSWERED" / 

"BCC" SP string / "BEFORE" SP string / 

"BODY" SP string / "CC" SP string / "DELETED" / 
"FLAGGED" / "KEYWORD" SP atom / "NEW" / "OLD" / 
"ON" SP string / "RECENT" / "SEEN" / 

"SINCE" SP string / "TEXT" SP string / 

"TO" SP string / "UNANSWERED" / "UNDELETED" / 
"UNFLAGGED" / "UNKEYWORD" / "UNSEEN") 


select ::= "SELECT" SP mailbox 

sequence ::= NUMBER / (NUMBER "," sequence) / (NUMBER ":" 
sequence) 

store ::= "STORE" SP sequence SP store att 

store_att ::= ("+FLAGS" SP flag list / "-FLAGS" SP flag list / 


"FLAGS" SP flag_list) 


string ::= atom / """" I]xcharacter "umm / literal 

system_flags ::= "\ANSWERED" SP "\FLAGGED" SP "\DELETED" SP 
"\ SEEN" 

tag ::= atom 

unsolicited ::= "*" SP (msg num SP msg data / data) CRLF 

userid ::= string 
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Implementation Status 
This information is current as of this writing. 


The University of Washington has developed an electronic mail client 
library called the "C-Client". It provides complete IMAP2, SMTP, and 
local mailbox (both /usr/spool/mail and mail.txt formats) services in 
a well-defined way to a user interface main program. Using the C- 
Client, the University of Washington has created an operational 
client for BSD Unix and two operational clients (one basic, one 
advanced) for the NeXT. 


Stanford University/SUMEX has developed operational IMAP2 clients for 
Xerox Lisp machines, Texas Instruments Explorers, and the Apple 
Macintosh. The core of the Macintosh client is an early version of 
the C-Client. SUMEX has also developed IMAP2 servers for TOPS-20 and 
BSD Unix. 


All of the above software is in production use, with enthusiastic 
local user communities. Active development continues on the 
Macintosh and C-Client based clients and the BSD Unix server. This 
software is freely available from the University of Washington and 
SUMEX. 


IMAP2 software exists for other platforms, for example Nippon 
Telephone and Telegraph (NTT) has developed an operational IMAP2 
client for the NTT ELIS. Several organizations are working on a PC 
client. 


IMAP2 can be used to access mailboxes at very remote sites, where 
echo delays and frequent outages make TELNET and running a local mail 
reader intolerable. For example, from a desktop workstation on the 
University of Washington local network the author routinely uses 
IMAP2 to read and manage mailboxes on various University of 
Washington local servers, at two systems at Stanford University, at a 
Milnet site, and at a site in Tokyo, Japan. 


This specification does not make any formal definition of size 
restrictions, but the DEC-20 server has the following limitations: 


length of a mailbox: 7,077,888 characters 
maximum number of messages: 18,432 messages 
length of a command line: 10,000 characters 
length of the local host name: 64 characters 
length of a "short" argument: 39 characters 
length of a "long" argument: 491,520 characters 
maximum amount of data output in a single fetch: 
655,360 characters 
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To date, nobody has run up against any of these limitations, many of 
which are substantially larger than most current user mail reading 
programs. 
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